\chapter{Problematiche} % Main chapter title

\label{Chapter2} % Change X to a consecutive number; for referencing this chapter elsewhere, use \ref{ChapterX}

\lhead{Capitolo 2. \emph{Problematiche}} % Change X to a consecutive number; this is for the header on each page - perhaps a shortened title

In questo capitolo verranno discusse le problematiche evidenziate nel corso dell'analisi del sistema richiesto, derivanti dalla tipologia del progetto e dalle caratteristiche esposte nel precedente capitolo.

%----------------------------------------------------------------------------------------
%	SECTION 1
%----------------------------------------------------------------------------------------

\section{Scelta del tipo di simulazione}

I tipi di simulazioni possibili possono dividersi in due categorie:
\begin{itemize}
 \item \textbf{Continua}: può essere rappresentata come una grande macchina a stati, in cui lo stato avanza solo quando tutte le operazioni correnti vengono completate. Vengono rappresentati tutti gli stati possibili. Spesso non è possibile garantire l'avanzamento a tempo reale perchè il tick di progressione richiede un tempo maggiore del periodo temporale rappresentato, in quanto l'aggiornamento di stato richiede di considerare un numero di variabili molto elevato.
 \item \textbf{Discreta}: l’avanzamento di stato avviene solo quando è necessario, e quindi non vengono rappresentati tutti gli stati, ma solo quelli significativi per l’architettura del sistema. In questo caso il tempo di avanzamento non è più lineare, e quindi una rappresentazione a tempo simulato risulta più complicata di quella a tempo reale.
\end{itemize}

%-----------------------------------
%	SECTION 2
%-----------------------------------
\section{Gestione del tempo}

In una simulazione di F1, una componente molto importante è rappresentata dal tempo. Ci sono due tipi di orologi utilizzabili:
\begin{itemize}
 \item \textbf{Clock assoluto}: usa il clock del pc per ottenere il tempo assoluto ad ogni avanzamento di stato
 \item \textbf{Tempo relativo}: ogni task usa un proprio orario, e calcola autonomamente il tempo relativamente a quello salvato
\end{itemize}

%-----------------------------------
%	SECTION 3
%-----------------------------------

\section{Rappresentazione delle componenti di gara}
Il circuito, inteso sia come sequenza di rettilinei e curve che lo definiscono, sia come spazio fisico in cui le macchine si spostano durante la gara, deve avere le seguenti caratteristiche:
\begin{itemize}
\item impone vincoli in grado di riprodurre i limiti fisici dello spazio
\item ottenibile in fase di configurazione
\item assimilabile ad un circuito reale
\end{itemize}

I veicoli, intesi come coppia pilota-vettura, possiedono una serie di parametri che devono essere ottenuti in fase di configurazione:
\begin{itemize}
\item identificativo univoco
\item accelerazione
\item velocità massima
\item comportamento di default
\end{itemize}

%----------------------------------------------------------------------------------------
%	SECTION 4
%----------------------------------------------------------------------------------------

\section{Determinismo}
Il determinismo è quella proprietà che assicura che partendo da un set di condizioni il risultato di uno stesso insieme di azioni sarà sempre lo stesso. In un simulatore questa proprietà è utile alla rappresentazione reale di un sistema, ma non per questo il non determinismo va evitato. In caso voglia essere riprodotto un comportamento reale non deterministico (come una gara automobilistica) può essere utile avere alcune componenti dal comportamento non predeterminato, assicurandosi però che siano controllate e che rispecchino l'imprevedibilità del sistema reale. Un esempio di comportamento non prevedibile è quello dello scheduler, che per quanto sia deterministico è indipendente dalla simulazione e quindi non è controllabile. Si presenta quindi il problema di separare il simulatore dall'architettura del sistema operativo su cui viene eseguito.

\section{Concorrenza}
Il problema richiede che il simulatore abbia componenti con esecuzione concorrente, ovvero la possibilità che un insieme di processi sia in esecuzione nello stesso istante e che interagiscano fra di loro attraverso l'utilizzo di risorse condivise.
L'utilizzo di concorrenza introduce diverse problematiche che verranno esposte di seguito.

 \subsection{Stalli}
 Dato che trattiamo un sistema concorrente, è importante assicurarci che non si verifichino stalli (o deadlock) durante l’esecuzione.
Affinchè possa verificarsi uno stallo, è necessario che le quattro condizioni di Havender vengano soddisfatte, ovvero:
\begin{itemize}
 \item \textbf{Mutua Esclusione}: una risorsa è in mutua esclusione quando può essere posseduta da un processo alla volta. Nel nostro caso ogni segmento di pista è stato implementato in questo modo.
 \item \textbf{Accumulo incrementale}: i processi che possiedono una risorsa la trattengono in attesa dell’acquisizione di altre. Ad esempio una macchina può chiedere l’accesso al segmento successivo essendo ancora nel precedente.
 \item \textbf{Impossibilità di prelazione}: un processo non può essere costretto a rilasciare una risorsa.
 \item \textbf{Attesa circolare}: avviene quando un gruppo di processi P1,...,Pn è in attesa di una risorsa posseduta dal processo successivo, creando una catena chiusa.
\end{itemize}
Le possibili soluzioni al deadlock sono due, risolverli o prevenirli.
Nel caso della risoluzione è necessario rimuovere forzatamente uno dei task che causa lo stallo, interrompendolo o usando il prerilascio, mentre per la prevenzione è sufficiente invalidare una delle quattro condizioni espresse sopra.

 \subsection{Sorpassi fisicamente impossibili}
 \label{sorpassimpossibili}
 Nel caso di una simulazione di corsa automobilistica è ragionevole pensare ai veicoli come task concorrenti e ai tratti come risorse condivise a cui essi accedono. In questa situazione è necessario risolvere il problema di garantire il corretto comportamento dei veicoli anche in situazioni di concorrenza, come ad esempio il seguente scenario:
 \begin{itemize}
 \item un veicolo A inizia l'attraversamento di un tratto
 \item il task veicolo A viene prerilasciato dallo scheduler
 \item un veicolo B richiede l'attraversamento dello stesso tratto
 \item il veicolo B termina l'attraversamento prima di A
 \item A viene mandato in esecuzione dallo scheduler e termina l'attraversamento in un istante temporalmente successivo a quello di B
 \end{itemize}
 Se il tratto preso in esame consentisse il transito ad un unico veicolo per volta questa situazione evidenzierebbe un sorpasso fisicamente impossibile, che va evitato.

\section{Distribuzione}
Uno dei requisiti del sistema è quello di essere distribuito, ovvero la possibilità di permettere la separazione dei componenti della simulazione su computer interconnessi fra loro. E' quindi necessario individuare quali componenti possono essere fisicamente separate fra loro in modo da garantire un corretto funzionamento complessivo.
\\
Bisogna inoltre stabilire quale protocollo di comunicazione utilizzare per l'interazione fra le varie componenti.